home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9703 / 000028_owner-urn-ietf _Wed Mar 12 13:14:12 1997.msg < prev    next >
Internet Message Format  |  1997-04-01  |  5KB
  1. Received: (from daemon@localhost)
  2.     by services.bunyip.com (8.8.5/8.8.5) id NAA02488
  3.     for urn-ietf-out; Wed, 12 Mar 1997 13:14:12 -0500 (EST)
  4. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
  5.     by services.bunyip.com (8.8.5/8.8.5) with SMTP id NAA02482
  6.     for <urn-ietf@services.bunyip.com>; Wed, 12 Mar 1997 13:14:09 -0500 (EST)
  7. Received: from mailhub.axion.bt.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  8.         id AA23169  (mail destined for urn-ietf@services.bunyip.com); Wed, 12 Mar 97 13:14:07 -0500
  9. Received: from ferao.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Wed, 12 Mar 1997 18:12:57 +0000
  10. Received: from phao.jungle.bt.co.uk by ferao.jungle.bt.co.uk (Jungle-SMTP-01) ID AA28956; Wed, 12 Mar 1997 18:08:21 GMT
  11. Message-Id: <3.0.32.19970312181527.006c6568@sherekhan.jungle.bt.co.uk>
  12. X-Sender: rbriscoe@sherekhan.jungle.bt.co.uk (Unverified)
  13. X-Mailer: Windows Eudora Pro Version 3.0 (32)
  14. Date: Wed, 12 Mar 1997 18:15:29 +0000
  15. To: "Ron Daniel Jr." <rdaniel@acl.lanl.gov>
  16. From: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
  17. Subject: Re: [URN] URNs grandfathering certain Object or Interface References
  18. Cc: urn-ietf@bunyip.com
  19. Mime-Version: 1.0
  20. Content-Type: text/plain; charset="us-ascii"
  21. Sender: owner-urn-ietf@Bunyip.Com
  22. Precedence: bulk
  23. Reply-To: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
  24. Errors-To: owner-urn-ietf@Bunyip.Com
  25.  
  26. Ron,
  27.  
  28. I'm off on leave tomorrow, so a quick answer...
  29.  
  30. At 10:22 12/03/97 -0700, Ron Daniel Jr. wrote:
  31. >Cheap answer #1 is that what you are asking for is a Turing-complete
  32. >way of operating on URIs. Declare a new flag, lets say "J", and use the
  33. >regexp field to carry Java bytecodes instead of regular expressions.
  34. >Clients that don't know the "J" flag ignore the record, those that do
  35. >know it could run the supplied bytecodes to learn how to crack such an
  36. >opaque identifier and what to do with the resulting pieces. For a
  37. >variety of reasons this is a bad idea, but is allowed by the draft.
  38. >(Well, change "J" to a digit and it is allowed as a local experiment. Try
  39. >to use an alphabetic flag and you will have to contend with people like me
  40. >on the list who will oppose doing such a thing).
  41.  
  42. Fine - or a further flag that indicates "expect the URN/URL of the bytecode"?
  43.  
  44. >
  45. >Cheap answer #2 is that we don't have to dump it all onto one global
  46. >resolver, we can use the "S" flag and a SRV record to dump it all onto
  47. >a resolver that is replicated to whatever degree one needs.
  48.  
  49. Not sufficient for CORBA/2 interoperability. The point is that domains can
  50. be isolated apart from a local ORB protocol-IIOP gateway, so need some way
  51. to identify which global replica is accessible protocol-wise.
  52.  
  53. >
  54. >Cheap answer #3 is that instead of using one central resolver, you use
  55. >some arbitrary subset of the characters in the identifier to distribute
  56. >the resolutions to an arbitrary number of resolver services. For IORs we
  57. >might use the last character, which will distribute the load to 16 possible
  58. >places. Use the last two and we can go 256 different places, ...
  59.  
  60. I believe a portion of the hex strong represents the resolution service
  61. scope that will give the right answer. CORBA/2 deliberately doesn't use
  62. global scope naming (hence my exhortation to read their case against global
  63. naming in the reply to Leslie). Accessing the resolver in the local context
  64. might give an answer but not the right answer, because names are context
  65. dependent.
  66.  
  67. >The real answer is more complex:
  68. >  a) What you are asking for is more than the NAPTR system is
  69. >     trying to solve. It is OK for us to start simple. There are
  70. >     a lot of important namespaces, such as ISBN, SICI, .. that can
  71. >     be handled using only syntactic transformations. NAPTR
  72. >     is intended to be the first, not last, resolver discovery
  73. >     service. Later ones can try to solve this problem directly if
  74. >     experience with NAPTR shows that it is a significant problem.
  75. >  b) NAPTR is intended to be a fallback resolution approach, and clients
  76. >     should try other things first. IORs are references to CORBA objects,
  77. >     and clients can invoke the object's methods, but only if they know IIOP
  78. >     or some other way to talk to the Object Request Broker associated with
  79. >     the object. Clients that speak IIOP should do so early on
  80. >     and not mess with NAPTR. Clients that don't speak IIOP might end up
  81. >     trying NAPTR and get back a record like:
  82. >
  83. >      ior.urn.net NAPTR 1 1 "p" "iiop" "" foo.omg.org
  84. >
  85. >     which tells them they need to know the IIOP protocol to do anything more
  86. >     with the identifier.
  87.  
  88. I think this is the correct answer, which I alluded to in my original posting:
  89.  
  90. >>Alternatively, given that Object systems have their own location
  91. transparency schemes, might URN not be relevant here (then we'd have to
  92. rename them FURNs (Fairly Universal [as opposed to Uniform] Resource
  93. Names)? I would have thought that if URN could be made relevant, it should
  94. be. 
  95.  
  96. I await the replies from Microsoft & OMG with antici...pation.
  97.  
  98. Bob
  99. ____________________________________________________________________________
  100. Bob Briscoe         http://www.labs.bt.com/people/briscorj/index.htm